home *** CD-ROM | disk | FTP | other *** search
/ WINMX Assorted Textfiles / Ebooks.tar / Text - Tech - Hacking - IP Address Spoofing (TXT).zip / eBook - TXT - IP Address - 28.4 KB.txt next >
Text File  |  2000-06-08  |  29KB  |  539 lines
  1.                 INTERNET HOLES - ELIMINATING IP ADDRESS FORGERY
  2.                                        
  3.   COPYRIGHT (C), 1996, MANAGEMENT ANALYTICS - ALL RIGHTS RESERVED
  4.   
  5.    
  6.      _________________________________________________________________
  7.    
  8. Series Introduction
  9.  
  10.    
  11.    
  12.    The Internet is now the world's most popular network and it is full of
  13.    potential vulnerabilities. In this series of articles, we explore the
  14.    vulnerabilities of the Internet and what you can do to mitigate them.
  15.    
  16. An Introduction IP Address Forgery
  17.  
  18.    
  19.    
  20.    The Internet Protocol (IP) (RFC791) provides for two and only two
  21.    functions. It defines a datagram that can be routed through the
  22.    Internet, and it provides a means for fragmenting datagrams into
  23.    packets and reassembling packets into the original datagrams. To quote
  24.    from RFC791:
  25.    The internet protocol is specifically limited in scope to provide the
  26.        functions necessary to deliver a package of bits (an internet
  27.        datagram) from a source to a destination over an interconnected
  28.        system of networks. There are no mechanisms to augment end-to-end
  29.        data reliability, flow control, sequencing, or other services
  30.        commonly found in host-to-host protocols. The internet protocol
  31.        can capitalize on the services of its supporting networks to
  32.        provide various types and qualities of service.
  33.        
  34.    
  35.    
  36.    Here's a description of an IP datagram, also from RFC791:
  37.  
  38.     0                   1                   2                   3
  39.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  40.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  41.    |Version|  IHL  |Type of Service|          Total Length         |
  42.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  43.    |         Identification        |Flags|      Fragment Offset    |
  44.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  45.    |  Time to Live |    Protocol   |         Header Checksum       |
  46.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  47.    |                       Source Address                          |
  48.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  49.    |                    Destination Address                        |
  50.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  51.    |                    Options                    |    Padding    |
  52.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  53.    |                             data                              |
  54.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  55.    |                             data                              |
  56.    \                                                               \
  57.    \                                                               \
  58.    |                             data                              |
  59.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  60.    |             data              |
  61.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  62.  
  63.                      Description of an IP Datagram
  64.  
  65.    
  66.    
  67.    Note that the 4th line of the description calls for the Source Address
  68.    of the datagram. In the simplest form of IP address forgery, the
  69.    forger only needs to create a packet containing a false Source Address
  70.    and insert it into the Internet by writing it into the output device
  71.    used to send information to the rest of the Internet. For the
  72.    non-expert forger, there is a tool called iptest which is part of the
  73.    free and publicly available ipfilter security package that
  74.    automatically forges packets for the purpose of testing configurations
  75.    or routers and other IP security setups.
  76.    
  77.    The infrastructure of the Internet consists primarily of a set of
  78.    gateway computers and packet routers. These systems have multiple
  79.    hardware interfaces. They maintain routing tables to let them decide
  80.    which output interface to send a packet out on based on the input
  81.    interface that it came in on and the destination IP address specified
  82.    in the packet. When a forged packet arrives at an infrastructure
  83.    element, that element will faithfully route the packet toward the
  84.    destination address, exactly as it would a legitimate packet.
  85.    
  86. How Can IP Address Forgery Be Used
  87.  
  88.    
  89.    
  90.    At its root, IP address forgery is a method of deception, and thus it
  91.    can be used in much the same way as other forms of deception.
  92.    Dunnigan95 More specifically, and using Dunnigan and Nofi's
  93.    classification scheme, here are some quick ideas about how IP address
  94.    forgery might be used:
  95.      * Concealment: IP address forgery is commonly used to conceal the
  96.        identity of an attacker, especially when denial of services is the
  97.        goal of the attack.
  98.      * Camouflage: IP address forgery is used to make one site appear to
  99.        be another as a way to convince the victim, for example, that an
  100.        attack is from a University, when in fact it is from a competitor.
  101.      * False and Planted Information: IP address forgery can be used to
  102.        create the impression that a particular site is acting maliciously
  103.        in order to create friction or lead a defender to falsely accuse
  104.        an innocent third party.
  105.      * Reuses: IP address forgery can be used to support another activity
  106.        designed to gain the confidence of the defender. For example, a
  107.        salesperson for information security products could create IP
  108.        address forgeries in order to convince a client of the need for
  109.        their services.
  110.      * Displays: IP address forgery has been used in order to lead
  111.        defenders to believe that many sites are participating in an
  112.        attack when in fact only a small number of individuals are
  113.        responsible.
  114.      * Demonstrations: IP address forgery has been used to demonstrate a
  115.        potential for untraceable attacks as a way to convince defenders
  116.        not to try to catch attackers.
  117.      * Feints: IP address forgery can be used to try to fool an enemy
  118.        into believing that an attack is coming from outside or from a
  119.        particular direction, when the real attack is very different. This
  120.        is a way to misdirect the enemy into spending limited resources in
  121.        the wrong way.
  122.      * Lies: IP address forgery has been used to create a more convincing
  123.        lie that somebody known to the defender is communicating with them
  124.        about a particular matter.
  125.      * Insight: IP address forgery can be used to gain insight into how
  126.        an opponent reacts and as a sort of probe to determine what sorts
  127.        of responses are likely to arise.
  128.        
  129.    
  130.    
  131.    Another way to view this issue is in terms of the net effect on
  132.    information in information systems. Here is another way of viewing
  133.    this issue with an example from each category.
  134.      * Corruption of Information: IP addresses are often used as the
  135.        basis for Internet control decisions. For example, DNS updates are
  136.        often designated as coming only from specific other servers. With
  137.        IP address forgery, the entire DNS system could be corrupted,
  138.        causing services to be rerouted through enemy servers.
  139.      * Denial of Services: The Internet is basically a fragile network
  140.        that depends on the proper behavior and good will of the
  141.        participants for its proper operation. Without wide-ranging
  142.        changes to the way the Internet works, denial of services is
  143.        almost impossible to prevent. For example, the same DNS attack
  144.        could be used to cause widespread denial of services, or perhaps
  145.        even to create loops in the packet delivery mechanisms of the
  146.        Internet backbone.
  147.      * Leakage of Information: Forged IP addresses can be used to cause a
  148.        host to take orders for the delivery of information to enemy sites
  149.        by forging authorization as if it were from a legitimate
  150.        authorizing site.
  151.      * Misplaced Liability: Forged IP addresses could be used, as
  152.        described above under False and Planted Information, to cause
  153.        defenders to assert claims against innocent bystanders and to lay
  154.        blame at the wrong feet.
  155.        
  156.    
  157.    
  158.    These are only some of the examples of what forged IP addresses can
  159.    do. Without a lot of effort, many other examples can be created.
  160.    
  161. What Can We Do About It?
  162.  
  163.    
  164.    
  165.     As individuals, there is little we can do to eliminate all IP address
  166.    forgery, but as a community, we can be very effective. Here's how.
  167.    Instead of having all infrastructure elements route all packets, each
  168.    infrastructure element could, and should, enforce a simple rule. They
  169.    should only route packets from sources that could legitimately come
  170.    from the interface the packet arrives on.
  171.    
  172.    This may sound complicated, but it really isn't. In fact, the
  173.    technology to do this is already in place, and always has been.
  174.    Virtually every router and gateway in existence today allows for the
  175.    filtering of packets based on their input interface and IP source and
  176.    destination address. This is a necessary component of their operation
  177.    and is the basis for the way they route all packets.
  178.    
  179.    The only change that has to be made is for these routers and gateways
  180.    to enforce the network structure that is legitimately in place. Or in
  181.    other words, the routers and gateways should refuse to route
  182.    ridiculous packets. Here are some of the simpler examples of known bad
  183.    packets:
  184.      * The IP address 127.0.0.1 is ONLY used for internal routing of
  185.        packets from a host to itself. There is no legitimate IP datagram
  186.        that should pass through a router or gateway with this as the
  187.        source address. In fact, routing these packets is dangerous
  188.        because they may be used to forge packets from the localhost which
  189.        often has special privileges. A recent attack that causes denial
  190.        of services involves sending a packet to a host's echo port with
  191.        127.0.0.1 as its source address and the echo port as it's source
  192.        port. The echo port causes whatever packet it is sent to be
  193.        returned to its source. Since the source address is the same port
  194.        on the same host, this packet creates an infinite loop which, in
  195.        many cases, disables the computer.
  196.      * The IP address 0.0.0.0 is not legitimate - full stop. In fact,
  197.        there's really no legitimate IP address that should traverse
  198.        gateways containing a 0 for one of the address elements.
  199.        Unfortunately, many routers use the '.0.' convention in their
  200.        filtering tables to indicate any address from 0 to 255 (the whole
  201.        range), so blocking these packets may be non-trivial in some
  202.        infrastructure elements.
  203.      * The IP specification includes provisions for private subnetworks
  204.        that are designated for internal use only. There is no legitimate
  205.        reason to route packets from these addresses anywhere in the
  206.        general Internet infrastructure. (RFC1597) These address ranges
  207.        include 10.*.*.*, 172.16-32.*.*, and 192.168.*.* (where *
  208.        indicates any value from 0 through 255). No packets should be
  209.        routed through the Internet with these addresses as either their
  210.        source or their destination.
  211.        
  212.    
  213.    
  214.    The next step in eliminating IP address forgery is for the routers and
  215.    gateways at each type of infrastructure element to enforce standards
  216.    on each interface. Generally, the Internet is broken up into Backbone
  217.    providers that provide wide area packet transport services, Private
  218.    Networks which are owned and operated by companies, institutions,
  219.    government agencies, and other parties for their own purposes, and
  220.    Internet Service Providers (ISPs) that provide connections between
  221.    the backbone elements and private networks (sometimes including other
  222.    ISPs). These roles can be blurred at times, but they are adequate for
  223.    our purposes.
  224.      * Private Networks: Each private network should;
  225.           + 1) prevent all of the known-bad packets from crossing into or
  226.             out of the organization,
  227.           + 2) prevent packets with internal source addresses from
  228.             passing inward,
  229.           + 3) prevent packets with external source addresses from
  230.             passing outward,
  231.           + 4) prevent packets with external destination addresses from
  232.             passing inward, and
  233.           + 5) prevent packets with internal destination addresses from
  234.             passing outward.
  235.      * ISPs: Each ISP should;
  236.           + 1) prevent all of the known-bad packets from crossing into or
  237.             out of their infrastructure,
  238.           + 2) prevent any packet inbound from any of their clients with
  239.             a source address not from that client's assigned address
  240.             range from passing from the client network,
  241.           + 3) prevent any packets with a destination address not in
  242.             their client's address range from passing to the client
  243.             network,
  244.           + 4) prevent any packet not from this ISP's legitimate address
  245.             range from entering the backbone, and
  246.           + 5) prevent any packets originating from the backbone and not
  247.             destined for one of their legitimate IP addresses from
  248.             entering their network.
  249.    Two additional rules will assist the ISP's clients;
  250.           + 6) prevent inbound traffic from the client with the client's
  251.             address as a destination, and
  252.           + 7) prevent outbound traffic to the client with the client's
  253.             address claimed to be the source.
  254.      * Backbone Networks: Each backbone provider should;
  255.           + 1) prevent all of the known-bad packets from crossing into or
  256.             out of their infrastructure,
  257.           + 2) prevent packets originating from any ISP with source
  258.             addresses not in that ISP's range of legitimate source
  259.             addresses from entering the backbone,
  260.           + 3) prevent any packets not destined for an ISP's address
  261.             range from entering that ISP,
  262.           + 4) prevent any packets from any other backbone provider that
  263.             could not be properly routed through that provider from
  264.             entering their backbone, and
  265.           + 5) prevent any packets from going to any other backbone
  266.             provider unless they could legitimately be routed through
  267.             that provider to reach their destination.
  268.    For backbones, this requires some effort, however the high volume of
  269.        information they carry certainly justifies a little effort for
  270.        protection.
  271.        
  272. Some Examples
  273.  
  274.    
  275.    
  276.     As an aide to the less technically inclined, the following examples
  277.    provide some real world implementation details.
  278.    
  279.    This set of rules applies to a private network (in this case, the
  280.    all.net class C network 204.7.229.*) and are written in the format of
  281.    the Morningstar PPP (point to point protocol) Filter file:
  282.  
  283. #       Rule 1 for private networks
  284. #       prevent known-bad address ranges from entering (or leaving)
  285. !172.16-32.0.0                     # private network segment
  286. !192.168.0.0                       # private network segment
  287. !10.0.0.0                          # private network segment
  288. !127.0.0.0                         # localhost network
  289. #       Rule 2 for private networks
  290. #       prevent internal source address packets from passing inward
  291. !recv/src/204.7.229.0              # prevent inbound from our network
  292. #       Rule 5 for private networks
  293. #       prevent internal destination addresses from passing outward
  294. #       Note that rule 5 is placed here because the filters are order dependent
  295. !send/dst/204.7.229.0              # prevent our destinations from passing out
  296. #       Rule 3 for private networks
  297. #       prevent external source address packets from passing outward
  298. send/src/204.7.229.0               # allow legitimate outbound sources
  299. !send/src/0.0.0.0                  # prevent illegitimate outbound sources
  300. #       Rule 4 for private networks
  301. #       prevent external destinations from passing inward
  302. recv/dst/204.7.229.0               # allow legitimate inbound destinations
  303. !recv/dst/0.0.0.0                  # prevent illegitimate inbound destinations
  304.  
  305.    
  306.    
  307.    The next set of rules applies to an ISP. In this case, we assume that
  308.    the ISP has control over three class B networks that it uses to sell
  309.    services to its clients. The class B networks used in this example
  310.    have IP addresses of 123.7.*.*, 231.6.*.*, and 201.96.*.*. In this
  311.    case, we have three different parts of the example:
  312.    
  313.    This is the router connecting the ISP to the backbone, presented in
  314.    the format of a Cisco router with interface 0 connected to the
  315.    backbone and interface 1 connected to the ISP's internal network. It
  316.    implements rules 1, 4, and 5 for the ISP.
  317.  
  318. #        Rule 1 for an ISP
  319. #        prevent all of the known-bad address ranges
  320. #        this should be done on all in and out connections
  321. #        on all interfaces in all access control lists
  322. All interfaces in and out
  323. deny ip 172.16-32.0.0              # private network segment
  324. deny ip 192.168.0.0                # private network segment
  325. deny ip 10.0.0.0                   # private network segment
  326. deny ip 127.0.0.0                  # localhost network
  327.  
  328. #        Rule 2 for an ISP
  329. #        prevent inbound from client not in client's address range
  330. #        DONE ELSEWHERE
  331.  
  332. #        Rule 3 for an ISP
  333. #        prevent entry of packets not destined clients from passing their way
  334. #        DONE ELSEWHERE
  335.  
  336. #        Rule 4 for an ISP
  337. #        prevent exit of packets not from our class Bs
  338. #        on interface 0 (backbone) out filter
  339. Interface 0 out
  340. permit ip 123.7.0.0
  341. permit ip 231.6.0.0
  342. permit ip 201.96.0.0
  343. deny   ip 0.0.0.0
  344.  
  345. #        Rule 5 for an ISP
  346. #        prevent entry of packets not destined for our class Bs.
  347. #        on interface 0 (backbone) in filter
  348. Interface 0 in
  349. permit ip 123.7.0.0
  350. permit ip 231.6.0.0
  351. permit ip 201.96.0.0
  352. deny   ip 0.0.0.0
  353.  
  354.    
  355.    
  356.    Next, we implement rules 2 and 3 for each client by creating separate
  357.    (in this example ppp) filters on the ISP's gateway computer. Again,
  358.    using the Morningstar ppp Filter format and assuming that Class C IP
  359.    network 201.96.1.* is assigned to this particular client:
  360.  
  361. #       Rule 1 for ISPs
  362. #       prevent known-bad address ranges from entering (or leaving)
  363. !172.16-32.0.0                      # private network segment
  364. !192.168.0.0                        # private network segment
  365. !10.0.0.0                           # private network segment
  366. !127.0.0.0                          # localhost network
  367. #        Rule 6 for an ISP
  368. #        prevent inbound traffic from the client destined for the client
  369. #        note that rule 6 is placed here because filters are order dependent
  370. !recv/dest/201.96.1.0               # prevent inbound from client to self
  371. #        Rule 7 for an ISP
  372. #        prevent outbound traffic to the client claimed to be from the client
  373. #        note that rule 7 is placed here because filters are order dependent
  374. !send/src/201.96.1.0                # prevent outbound to client from client
  375. #        Rule 2 for an ISP
  376. #        prevent inbound from client not in client's address range
  377. recv/src/201.96.1.0                # allow legitimate traffic
  378. !recv/src/0.0.0.0                  # prevent all other traffic
  379. #        Rule 3 for an ISP
  380. #        prevent entry of packets not destined clients from passing their way
  381. send/dest/201.96.1.0               # allow legitimate traffic
  382. !send/dest/0.0.0.0                 # prevent all other traffic
  383.  
  384.    
  385.    
  386.    Note that redundant protection is provided in several ways. The ISP
  387.    protects the clients from backbone forgery both at the backbone router
  388.    and at the client's ppp connection, and protects the backbone from IP
  389.    forgery emanating from the ISP both by preventing forgery from clients
  390.    and by preventing forgery from within the ISP. Similarly, the ISP
  391.    provides redundant protection against improperly configured client
  392.    hardware and software. The last two filter rules are to assure that
  393.    even if the client is not properly configured to prevent forgery of
  394.    internal addresses from the outside world or to prevent internal
  395.    traffic from being sent out, this traffic is prevented.
  396.    
  397.    This last example is a simplification of a wide area backbone network
  398.    in which this particular router (no type specified) is at the junction
  399.    between UK connections and non-UK connections. In this case, it is a
  400.    reasonable assumption that all internal UK traffic should remain
  401.    internal and that external traffic that gets to this node should be
  402.    sent out of the UK never to return. This particular backbone node will
  403.    be connected to non-UK traffic on interface 0, our previously
  404.    described ISP on interface 1, and the rest of the internal UK backbone
  405.    on interface 2.
  406.  
  407. #        Rule 1 for a backbone
  408. #        prevent all of the known-bad packets from crossing
  409. all-interfaces prevent in/out 172.16-32.0.0     # private network segment
  410. all-interfaces prevent in/out 192.168.0.0       # private network segment
  411. all-interfaces prevent in/out 10.0.0.0          # private network segment
  412. all-interfaces prevent in/out 127.0.0.0         # localhost network
  413.  
  414. #        Rule 2 for a backbone
  415. #        prevent packets originating from any ISP with non-ISP source address
  416. interface-1 allow in from 123.7.0.0                  # ISP traffic
  417. interface-1 allow in from 231.6.0.0                  # ISP traffic
  418. interface-1 allow in from 201.96.0.0                 # ISP traffic
  419. interface-1 prevent in from 0.0.0.0                  # no other inbound traffic
  420.  
  421. #        Rule 3 for a backbone
  422. #        prevent packets not destined for an ISP from going there
  423. interface-1 allow out to 123.7.0.0                 # ISP traffic
  424. interface-1 allow out to 231.6.0.0                 # ISP traffic
  425. interface-1 allow out to 201.96.0.0                # ISP traffic
  426. interface-1 prevent out to 0.0.0.0                 # no other outbound traffic
  427.  
  428. #        Rule 4 for a backbone
  429. #        prevent packets from other backbones that shouldn't come this way
  430. interface-0 allow in to UK-1                       # UK traffic
  431. interface-0 allow in to UK-2                       # UK traffic
  432. ...
  433. interface-0 allow in to UK-n                       # UK traffic
  434. interface-0 prevent in to 0.0.0.0                  # no other inbound traffic
  435.  
  436. #        Rule 5 for a backbone
  437. #        prevent packets that should stay in our backbone from going out
  438. interface-0 allow out from UK-1                    # UK traffic
  439. interface-0 allow out from UK-2                    # UK traffic
  440. ...
  441. interface-0 allow out from UK-n                    # UK traffic
  442. interface-0 prevent out from 0.0.0.0               # no other outbound traffic
  443.  
  444.    
  445.    
  446.    In this example, we have assumed that all UK traffic is on IP
  447.    addresses identified as UK-1, ..., UKn.
  448.    
  449. What-ifs and Objections
  450.  
  451.   WHAT IFS?
  452.      * What if a private network ignores the rules? It is to be expected
  453.        than many private networks will ignore any such rules, either
  454.        through ignorance, intent, or inattention. But even if all private
  455.        networks ignored all of the rules, the rules for ISPs would
  456.        prevent IP forgery from extending to the overall infrastructure.
  457.      * What if an ISP ignores the rules? If an ISP ignores the rules and
  458.        allows IP forgery, the backbone can protect the rest of the
  459.        Internet, at least to the point where forged packets within the
  460.        ISP's domain remain within or are traceable to that domain. That
  461.        means that the ISP's clients would be subject to IP forgeries from
  462.        other clients of that ISP, but that the rest of the Internet would
  463.        be able to trace all packets coming from that ISP to that ISP.
  464.      * What if the backbone ignores the rules? If all of the backbone
  465.        providers ignore the rules, unless everyone else follows them, we
  466.        will continue to have IP forgeries through the ISPs that don't
  467.        follow the rules.
  468.      * What if combinations ignore the rules? Depending on the specific
  469.        combinations, we will have more or fewer IP address forgeries. It
  470.        turns out that a complete analysis of this issue is not simple
  471.        enough to do in the space provided, but a simple conclusion can be
  472.        drawn without a full analysis. As more Internet users and
  473.        providers prevent IP address forgery, the job of the forger will
  474.        become harder and harder. We don't all have to participate in
  475.        order to have proper protection, but if we all fail to
  476.        participate, the forgeries will continue.
  477.        
  478.   OTHER OBJECTIONS
  479.      * Content (common carrier) objections: Many ISPs and backbone
  480.        providers don't want or take responsibility for content in the
  481.        Internet. Just like a telephone company, they don't want any role
  482.        in examining or dictating the content of the messages - they only
  483.        want to be a delivery service. It could be argued that examining
  484.        the address information in an IP packet and preventing packets
  485.        based on those addresses constitutes limitation of content. Of
  486.        course the portion of the content involved here must be examined
  487.        in order to route the information, and the routing used in the
  488.        Internet already provides exclusion of packets based on IP address
  489.        ranges. Furthermore, common carriers (in the U.S.) are allowed to
  490.        listen to and filter traffic to the extent that this activity is
  491.        done solely to assure the proper operation of the network. Thus
  492.        this objection would seem to be moot.
  493.      * The cost is too high objection: In fact the cost is negligible. If
  494.        the rules set forth herein were applied as a normal part of the
  495.        installation and maintenance process, it would come to only a few
  496.        minutes of effort during each installation. Even applying them to
  497.        systems already in place requires only a few minutes of effort,
  498.        again an insubstantial amount of effort well within the discretion
  499.        of any systems administrator.
  500.      * The we don't want restrictions objections: There are a substantial
  501.        number of people that want a total lack of restrictions on
  502.        information flowing through the Internet. I generally agree with
  503.        the principle of free information flow, except in cases where the
  504.        freedom of one person infringes on the freedom of others. This
  505.        impingement on other peoples' rights applies to certain types of
  506.        information, such as routing information, that must be correct in
  507.        order for the Internet to work properly. Since the restrictions
  508.        described here only assure that the Internet works properly and
  509.        don't restrict the content or flow of information, there is no
  510.        restriction of the free flow of information here. Only increased
  511.        assurance that those who want to use the media for legitimate
  512.        purposes will continue to be able to do so.
  513.        
  514. Summary
  515.  
  516.    
  517.    
  518.    This solution we presented:
  519.      * 1) is easy to implement,
  520.      * 2) makes good sense from a traffic standpoint,
  521.      * 3) allows all legitimate activity without any hinderence,
  522.      * 4) works even if all parties don't participate,
  523.      * 5) costs almost nothing to implement at each site,
  524.      * 6) does not require any changes in existing protocols of traffic
  525.        patterns,
  526.      * 7) makes good sense for the security of each party that
  527.        participates, and
  528.      * 8) can be done today.
  529.        
  530.    
  531.    
  532.    All that remains is for the people in each of these organizations to
  533.    implement these protections. Unlike so many of the problems in the
  534.    Internet that are hard to solve and will require years of evolution,
  535.    this problem can be solved now. We encourage you to implement these
  536.    protections at your earliest convenience and to urge other to do so as
  537.    well. Together, we can eliminate IP address forgery.
  538.    
  539.